Digital content distribution system

ABSTRACT

A method of generating cryptographically protected digital data encoding content and arranged into messages each message being decodable by a decoder application on a client terminal having a service interface to assemble each message for the decoder application are described. The method can include retrieving a message encrypting at least part of the message; and providing the encrypted messages as output in a format enabling a server service interface to arrange the message into at least one packet including at least one header and a payload. In an example, the encrypted message is assembled by adding a resynchronisation marker, separating a message section from an adjacent message section and including explicit synchronisation information, to at least the further message sections.

The present patent application claims the priority benefit of the filingdate of PCT Application No. PCT/EP02/14828 filed Dec. 18, 2002 and U.S.Provisional Application No. 60/342,718 filed Dec. 19, 2001.

BACKGROUND OF THE INVENTION

1. Technical Field

This invention relates to cryptographic protocols for use, for example,in performing effective content level encryption (e.g., on MPEG-4 bitstreams).

2. Summary

In particular, the invention relates to a method of generatingcryptographically protected digital data encoding content and arrangedinto messages, each message being decodable by a decoder application ona client terminal having a service interface to assemble each messagefor the decoder application, the method including:

-   retrieving a message from a machine-readable medium;-   encrypting at least part of the message; and-   providing the encrypted messages as output in a format enabling a    server service interface to arrange the message into at least one    packet including at least one header and a payload, each payload    including at least part of the message, at least one header    including information enabling the service interface on the client    to assemble each message for the decoder application from the    payload of the packets.

The invention further relates to a server for enabling decryption ofcryptographically protected data encoding content and arranged intomessages, generated by means of such a method.

The invention also relates to a system for generating cryptographicallyprotected digital data encoding content and arranged into messages, eachmessage being decodable by a decoder application on a client terminalhaving a service interface to assemble each message for the decoderapplication, the system being configured to:

-   retrieve a message from a machine-readable medium;-   encrypt at least part of the message; and to-   provide the encrypted messages as output in a format enabling a    server service interface to arrange the message into at least one    packet including at least one header and a payload, each payload    including at least part of the message, at least one header    including information enabling the service interface on the client    to assemble each message for the decoder application from the    payload of the packets.

The invention further relates to a method of distributing digital dataencoding content and arranged into messages from a server to one or moreclient terminals through a network, each message being decodable by adecoder application on a client terminal, said method including:

-   transmitting a plurality of data packets from the server through a    network through a network interface of the server, each packet    including at least one header and a payload, each payload including    at least part of a message;-   providing each message to a first of a series of at least one    service interface between two layers in a protocol stack, installed    on the server, each service interface configured to add at least one    packet header to the packet encoding information enabling the client    to process the remainder of the packet, the method further    comprising transmitting packets including at least one header    including information enabling a service interface on the client to    assemble each message for the decoder application from the payload    of the packets.

The invention also relates to a server for distributing digital dataencoding content and arranged into messages to one or more clientterminals through a network, each message being decodable by a decoderapplication on a client terminal, said server including:

-   a network interface for transmitting a plurality of data packets    from the server through a network, each packet including at least    one header and a payload, each payload including at least part of a    message, the server further including a series of at least one    service interface between two layers in a protocol stack, each    service interface configured to add at least one packet header to    the packet encoding information enabling the client to process the    remainder of the packet, the server being configured to transmit    packets including at least one header including information enabling    a service interface on the client to assemble each message for the    decoder application from the payload of the packets.

The invention also relates to a client terminal for receiving andprocessing digital data encoding content and arranged into messages,each message being decodable by a decoder application, comprising

-   an interface for receiving a plurality of data packets, each packet    including at least one header and a payload, the terminal further    including a series of at least one service interface between two    layers in a protocol stack, each service interface configured to    remove at least one packet header from the packet and process the    remainder of the packet using information encoded in the removed    packet header, including a service interface configured to assemble    the messages for the decoder application from the payload of at    least one packet, using information included in at least one header    of the packet.

The invention also relates to a method for receiving and processing in aclient terminal digital data encoding content and arranged intomessages, each message being decodable by a decoder application,comprising

-   receiving a plurality of data packets by means of an interface of    the client terminal, each packet including at least one header and a    payload;-   providing each packet to a first of a series of at least one service    interface between two layers in a protocol stack, each service    interface configured to remove at least one packet header from the    packet and process the remainder of the packet using information    encoded in the removed packet header, including a service interface    configured to assemble the messages for the decoder application from    the payload of at least one packet, using information included in at    least one header of the packet.

The invention also relates to a computer program loadable into acomputer and having the potential, when run on the computer, to providethe computer with the functionality of such a system, server or clientterminal.

The invention lastly relates to a computer program loadable into acomputer and having the potential, when run on the computer, to enablethe computer to execute one of the above-mentioned types of methods.

Examples of such systems and methods are known, e.g. from internationalstandard ISO/IEC 14496-1, known as MPEG (Moving Pictures ExpertGroup)-4.

MPEG and MPEG-4 are standards that have been proposed and, in the caseof MPEG, are widely used in the distribution of video and, to a lesserdegree, other forms of content. Moreover, applications such asdistributing digital content over the Internet and others, have createda need for encrypting content, whether in the MPEG, MPEG-4 or any otherformat.

The MPEG-4 standard specifies an architecture of which the basicbuilding blocks are formed by a scene description and elementary streamsthat convey streaming data. To distribute the streaming data, it isconveyed in SL-packetised streams (SPS). The packets contain elementarystream data partitioned in access units as well as side information,e.g. for timing and access unit labelling. The timing model relies onclock references and time stamps to synchronise audio-visual dataconveyed by the one or more elementary streams. The concept of a clockwith its associated clock references is used to convey the notion oftime to a receiving terminal. Time stamps are used to indicate theprecise time instants at which the receiving terminal consumes theaccess units in decoding buffers. An object time base (OTB) defines thenotion of time for a given data stream. The resolution of this OTB canbe selected as required by the application or as defined by a profile.All time stamps that the sending terminal inserts in a coded data streamrefer to this time base. The OTB of a data stream is known at thereceiving terminal by means of object clock reference (OCR) time stampsin the SL packet headers for this stream or by means of an indication ofthe elementary stream from which this object descriptor stream inheritsthe time base.

The object description framework consists of a set of descriptors thatallows to identify, describe and properly associate elementary stream toeach other and to audio-visual objects used in the scene description.Object descriptors are a collection of descriptors that describe one ormore elementary streams that are associated to a single node in thescene. An elementary stream descriptor within an object descriptoridentifies a single elementary stream. Each elementary stream descriptorcontains the information necessary to initiate and configure thedecoding process for the elementary stream, as well as intellectualproperty identification. Intellectual Property Management and Protection(IPMP) information is conveyed both through IPMP descriptors as part ofthe object descriptor stream and through IPMP streams, elementarystreams that carry time variant IPMP information, in particular contentencryption keys. Keys are associated with the content or other streamsvia appropriate IPMP stream descriptors. These keys must be synchronisedwith the content stream. The existing MPEG-4 model is used for delay andsynchronisation management. Thus, the decryption application in thereceiving terminal must appropriately manage time stamping.

The MPEG-4 bit stream syntax in its current form offers no explicitsupport for resynchronisation of the decryption process in the eventthat parts of the encrypted content bit stream are lost duringtransmission. Since the transport layer is not specified by MPEG-4 it isnot possible to utilize characteristics of the underlying transportprotocol for synchronization. MPEG-4 media may also be played backlocally, in which case there is no transport involved. In an error-proneenvironment, the loss of a single bit would effectively destroy theremainder of the frame. There are many ciphers and associated modes thatcannot perform self-synchronization, but that are very attractive undera wide range of evaluation criteria. Currently, these must all be ruledout, simply because there is not support in the extensions for thesynchronization of the decryption process in the event of data loss.

SUMMARY OF THE INVENTION

The present invention provides a method and system for generatingcryptographically protected digital data encoding content and fordistributing the digital data, and a client terminal and method forreceiving and processing the digital data of the type mentioned above,that implement a data distribution system in which the content isadequately protected against unauthorised access and which showsimproved error resilience.

The invention achieves this by providing a method of generatingcryptographically protected digital data encoding content and arrangedinto messages, each message being decodable by a decoder application ona client terminal having a service interface to assemble each messagefor the decoder application, the method including:

-   retrieving a message from a machine-readable medium; encrypting at    least part of the message; and-   providing the encrypted messages as output in a format enabling a    server service interface to arrange the message into at least one    packet including at least one header and a payload, each payload    including at least part of the message, at least one header    including information enabling the service interface on the client    to assemble each message for the decoder application from the    payload of the packets, wherein the method comprises separating each    message into a first and at least one further message section,    wherein at least one of the message sections is encrypted in such a    way as to be decryptable independently of the other message    sections, and wherein the encrypted message is assembled by adding a    resynchronisation marker, separating a message section from an    adjacent message section and including explicit synchronisation    information, to at least the further message sections.

A message is the unit of data that is transmitted from the encoderprogram that encoded the content to the decoder application on theclient, which is arranged to process the individual messages to decodethe content. The content may, for example, be video, audio, or text. Aservice interface is an interface implementing part of a protocol in aprotocol stack and providing a communication service that applicationsat one level of the protocol stack can use to exchange messages, usingthe functionality of protocols at a different level in the protocolstack. Advantageously, this is a network protocol stack, for exampleconform the OSI network architecture. However, the service interface mayalso provide an interface between application programs and a system'soperating system, translating, for example the message into packetsdefined for the file system of the operating system. The term“independently” is used to indicate that each encrypted message sectioncan be decrypted without knowledge of the ciphertext or plaintext ofanother message section. In the context of the present application, aheader is a piece of data preceding or following the payload of a packetand encoding information describing something about the packet or itspayload. A packet is a self-contained, independent entity of datacarrying sufficient information to be routed from a source to adestination without reliance on earlier exchanges between this sourceand destination and the interface between them.

Because each message section is independently decryptable, and becausethe resynchronisation markers provide an explicit indication of theboundaries between adjacent encrypted message sections, an error or lossof data in one section does not influence the client's ability todecrypt the other message sections. In other words, the lack of all orpart of any preceding data blocks does not influence the ability todecrypt the current data block in the client. By adapting the size ofthe message sections, and thus the number of resynchronisation markers,more or less resilience can be provided. Furthermore, it is possible toencrypt only a few of the sections of a message, reducing the amount ofdecryption processing time and power required of the client.

It is noted that the MPEG-4 bit stream syntax defines resynchronisationmarkers (Resync Markers). Resync Markers offer error resilience byincreasing the opportunities for resynchronisation between the decoderand the bit stream after a residual error or errors have been detected.Typically, data between the synchronization point prior to the error andthe point at which resynchronisation is established is discarded. Thesemarkers are guaranteed to be unique for valid, unencrypted MPEG-4content. While this construct works well for clear content, it is notvery well suited to content that is encrypted after being coded. Thisseems to hold regardless of whether selective encryption or brute forceencryption of the entire message is used. This is so, because while itis not possible for valid clear content to emulate a Resync Marker, thisdoes not hold for encrypted data. More importantly, the MPEG-4 standarddoes not disclose encrypting at least one of the message sections insuch a way as to be decryptable independently of the other messagesections, so that, in case of data loss, complicated and ofteninadequate error recovery techniques are needed to re-construct thecomplete message, before it can be decrypted by the client.

In a preferred embodiment of the invention, the message sections areencrypted using at least one key having a cycling value.

Thus, improved security against cryptographic analysis on distributedcontent data is provided.

Preferably, each resynchronisation marker further includes a uniquesequence number.

The usage of sequence numbers addresses all of the problems surroundingthe requirement to allow random access into the encrypted media stream.It provides a cryptographic framework that enables synchronisation ofcycling session keys with associated media and does not impose statedependency on either the sender or receiver in a content distributionsystem.

The MPEG-4 bit stream syntax in its current form offers no explicitsupport for resynchronisation of the decryption process in the eventthat the user performs a random seek into the encrypted content bitstream. At the content-level, MPEG-4 does not specify any dependablecontinuity or sequencing information that may be relied on duringdecryption. Use of Sync Layer information is problematic, sincetraditionally all SL information is discarded prior to decryption.Retention and delivery of SL information to an IPMP tool would representa significant obstacle for most terminal implementations. Timinginformation cannot be used for synchronisation, since DTS/CTS may changefrom the time that the content is secured, to the point where content isconsumed.

Traditionally, media formats have used explicit sequencing informationand/or uniform packet size in order to aid the encryption/decryptionprocesses. MPEG-4 media may also be played back locally, in which casethere is not transport involved. Even if one could define a normativemapping to the transport layer sequencing information, this would be oflittle help, since this information is not known at the time that themedia is secured.

The availability of a unique sequence number allows for effectivemanagement of transitions during key cycling. A sequence number allowspackaging and delivery of the content from a media server whiledelivering keys independently from that server in a reliable way (suchas media carried on MPEG-2 or stored on DVD/CD-ROM and IPMP carried onIP (Internet Protocol) networks ahead of time). The presence of uniquesequence information also allows for sending the entire key stream priorto the delivery of any media.

Although the MPEG-4 IPMP Message stream provides the ability to delivercycled session keys in band, the MPEG-4 standard fails to provide areliable mechanism whereby the timing of the delivery of a new key maybe related to a particular media access unit.

Media Time (DTS/CTS) cannot be used for this purpose, since this maychange from the time that the content is secured, to the point where thecontent is consumed.

Furthermore, media streams and IPMP message streams carrying decryptionkeys could suffer very different delivery jitters, packet loss ornetwork congestion and a tight synchronisation using time-stamps wouldbe almost impossible to achieve if IPMP message streams are sent to theclient from a different server. As no association exists between mediapayloads and keys, a delay in an IPMP AU would result in decryptionusing an incorrect key. The loss of synchronisation of even a singleframe per key period is completely unacceptable.

A preferred embodiment of the method according to the invention furthercomprises adding a wrapper that encapsulates each encrypted message andincludes a unique sequence number.

A wrapper is the data that is put in front of or around the message thatprovides information about it and may also encapsulate it from view toanyone other than the intended recipient. A wrapper may consist ofeither a header that precedes the encapsulated data, or a trailer thatfollows it, or both.

By using a wrapper with a unique sequence number, sequencing informationis also attributed to the first message section in the message, whichneed not necessarily carry a resynchronisation marker with explicitsynchronisation information.

Preferably, each unique sequence number is provided in a self-describingformat.

Thus, the sequence numbers can be of variable length, allowing for adecrease in data addition.

A preferred embodiment of the method according to the invention furthercomprises generating at least one key message, each key message carryingdata linking at least one unique sequence number added to a message to akey value enabling decryption of at least parts of that message.

This information can be used to associate key data with access unit datato any granularity, regardless of the receiving terminal clockresolution.

An advantageous embodiment of the method according to the inventionfurther comprises encrypting message sections by employing a cipher in acryptographic mode using feedback, wherein the cipher is re-initialisedat the start of each message section.

The use of feedback, also known as chaining, provides additionalsecurity. It ensures that identical plaintext blocks are not encryptedto identical ciphertext blocks. It also provides protection againstblock replay attacks. By re-initialising the cipher at the start of eachmessage section, it is ensured that each message section that isencrypted can be independently decrypted. Encryption of more than onemessage with the same product or session key is possible withoutcompromising security in any way. The use of explicit or implicit IVscan be assumed in order to prevent use of the cipher in depth.

Schneier, B., “Applied Cryptography”, describes a number ofcryptosystems that address the issue of random access with varyinglevels of success. Ciphers and modes that operate in a non-chaining modemeet the criterion of not adding overhead or performing badly in a lossyenvironment. Electronic Codebook Mode (ECB) has disadvantages for thepresent application of encryption, since data patterns are not hidden(identical ciphertext blocks imply identical plaintext blocks).

In a preferred variant of the last-mentioned embodiment, a uniquesequence number in a resynchronisation marker separating a furthermessage section from another message section is used as aninitialisation vector to encrypt the further message section.

Thus, the decryption process can be synchronised in the event of dataloss or random seeking into the media.

Techniques such as ECB+OFB (Electronic Codebook Mode+Output FeedbackMode) and CBC (Cipher Block Chaining) with implicit IV generation eitheradd overhead of perform badly in a lossy environment. Generating animplicit IV (initialisation vector) from some characteristics of themessage seems to be problematic, since a bit error or data loss of theIV data leads to the garbling of all the plaintext. There are manyciphers and associated modes that cannot perform self-synchronisation,but that are very attractive under a wide range of evaluation criteria.Currently, these must all be ruled out, simply because there is notsupport in the extensions for the synchronisation of the decryptionprocess in the event of data loss or random seeking into the media.While an explicit sequence number alone does not provide any protectionagainst complete loss of plaintext in the event of a bit error in thesequence number, it does lend itself to error correction. Together withresynchronisation markers it serves to limit the damage caused by biterror in the sequence numbers themselves.

Content varies greatly in complexity and value. The present solutionallows support for encryption across this entire spectrum. This maynecessitate very efficient, lightweight algorithms that provideacceptable levels of security. Additive stream ciphers are idealsolutions, but require the presence of implicit or explicit sequencinginformation, the latter being provided by this embodiment of theinvention.

According to a further aspect of the invention, there is provided aserver for enabling decryption of cryptographically protected dataencoding content and arranged into messages, generated by means of amethod according to the invention, wherein the server is arranged totransfer at least one key message, each key message carrying datalinking at least one unique sequence number added to a message to a keyvalue enabling decryption of at least parts of that message, in responseto a request from a client terminal, connected to the server through anetwork.

Thus, the key messages are distributed from a separate server, allowingseparation of the functions of distributing the encrypted content anddistribution of the key message stream enabling decryption of thecontent. This also allows a separate entity to take care of charging forand controlling decryption of the content.

According to another aspect of the invention, there is provided a systemfor generating cryptographically protected digital data encoding contentand arranged into messages, each message being decodable by a decoderapplication on a client terminal having a service interface to assembleeach message for the decoder application, the system being configuredto:

-   retrieve a message from a machine-readable medium;-   encrypt at least part of the message; and to-   provide the encrypted messages as output in a format enabling a    server service interface to arrange the message into at least one    packet including at least one header and a payload, each payload    including at least part of the message, at least one header    including information enabling the service interface on the client    to assemble each message for the decoder application from the    payload of the packets, wherein the system is configured to separate    each message into a first and at least one further message section,    to encrypt at least one of the message sections in such a way as to    be decryptable independently of the other message sections, and to    assemble the encrypted message by adding a resynchronisation marker,    separating a message section from an adjacent message section and    including an explicit synchronisation sequence, to at least the    further message sections.

This system is essentially arranged to carry out the various embodimentsof the method of the invention just described above, and provides theassociated advantageous effects.

According to another aspect of the invention, there is provided a methodof distributing digital data encoding content and arranged into messagesfrom a server to one or more client terminals through a network, eachmessage being decodable by a decoder application on a client terminal,said method including:

-   transmitting a plurality of data packets from the server through a    network through a network interface of the server, each packet    including at least one header and a payload, each payload including    at least part of a message;-   providing each message to a first of a series of at least one    service interface between two layers in a protocol stack, installed    on the server, each service interface configured to add at least one    packet header to the packet encoding information enabling the client    to process the remainder of the packet, the method further    comprising transmitting packets including at least one header    including information enabling a service interface on the client to    assemble each message for the decoder application from the payload    of the packets, wherein packets are transmitted having a packet    payload including a first section and at least one further section,    each further section including a resynchronisation marker separating    a message section from an adjacent message section and including an    explicit synchronisation sequence, at least one of the message    sections being encrypted in such a way as to be decryptable    independently of the other message sections.

Thus, a method is provided for distributing content such as may begenerated using an embodiment of the method for generatingcryptographically protected digital data encoding content according tothe invention. It is particularly useful for providing resilienceagainst errors and jitter introduced by the network.

According to another aspect of the invention, there is provided a serverfor distributing digital data encoding content and arranged intomessages to one or more client terminals through a network, each messagebeing decodable by a decoder application on a client terminal, saidserver including:

-   a network interface for transmitting a plurality of data packets    from the server through a network, each packet including at least    one header and a payload, each payload including at least part of a    message, the server further including a series of at least one    service interface between two layers in a protocol stack, each    service interface configured to add at least one packet header to    the packet encoding information enabling the client to process the    remainder of the packet, the server being configured to transmit    packets including at least one header including information enabling    a service interface on the client to assemble each message for the    decoder application from the payload of the packets, wherein the    server is configured to distribute packets having a packet payload    including a first section and at least one further section, each    further section including a resynchronisation marker separating a    message section from an adjacent message section and including an    explicit synchronisation sequence, at least one of the message    sections being encrypted in such a way as to be decryptable    independently of the other message sections.

This server is useful for carrying out the method of distributingcontent according to the invention.

According to another aspect of the invention, there is provided a clientterminal for receiving and processing digital data encoding content andarranged into messages, each message being decodable by a decoderapplication, comprising

-   an interface for receiving a plurality of data packets, each packet    including at least one header and a payload, the terminal further    including a series of at least one service interface between two    layers in a protocol stack, each service interface configured to    remove at least one packet header from the packet and process the    remainder of the packet using information encoded in the removed    packet header, including a service interface configured to assemble    the messages for the decoder application from the payload of at    least one packet, using information included in at least one header    of the packet, wherein the terminal is configured to receive packet    payloads including a first section and at least one further section,    each further section including a resynchronisation marker separating    a message section from an adjacent message section and including an    explicit synchronisation sequence, to extract each section by    locating the resynchronisation markers, to decrypt each encrypted    message section independently of the other message sections, and to    insert each decrypted message section in the place of the section    from which it was extracted.

The client terminal is able to recover large portions of the encryptedmessage if errors are introduced into the message during transmission.An error in one of the message sections enables all of the other messagesections to be decrypted to the original plaintext message sections, asthe client system is able to locate each individual message section anddecrypt it independently of the other message sections, i.e. withoutknowledge of the ciphertext or plaintext of the other message sections.

In a preferred embodiment, the terminal is configured to re-assemble atleast part of each received packet after decryption, by adding at leastone of the headers of each packet to the payload with the inserteddecrypted message sections, before passing it to the service interface.

Thus, the presence of resynchronisation markers allows the payload of apacket to be decrypted before it is processed by the interfacesimplementing the protocol stack on the client system, which can be anetwork protocol stack, for example. This provides increased efficiencyand allows independence of the particular protocol stack used.

Preferably, the client terminal further comprises a network interfacedevice for receiving the data packets from a server through a network,wherein the added headers include a header including a network address,identifying the client terminal as intended recipient of the packet.

In this variant, decryption is completely carried out “under the stack”.There is thus provided a conditional access system that is universallyusable, regardless of the particular kind of terminal and networkprotocol.

According to a further aspect of the invention, there is provided amethod for receiving and processing in a client terminal digital dataencoding content and arranged into messages, each message beingdecodable by a decoder application, comprising

-   receiving a plurality of data packets by means of an interface of    the client terminal, each packet including at least one header and a    payload;-   providing each packet to a first of a series of at least one service    interface between two layers in a protocol stack, each service    interface configured to remove at least one packet header from the    packet and process the remainder of the packet using information    encoded in the removed packet header, including a service interface    configured to assemble the messages for the decoder application from    the payload of at least one packet, using information included in at    least one header of the packet, wherein packet payloads are received    comprising a first section and at least one further section, each    further section including a resynchronisation marker separating a    message section from an adjacent message section and including an    explicit synchronisation sequence, wherein each section is extracted    by locating the resynchronisation markers, and wherein each    encrypted message section is decrypted independently of the other    message sections, and each decrypted message section is inserted in    the place of the section from which it was extracted.

This method is the method implemented by the client terminal accordingto the invention, and has essentially the same advantages in terms oferror resilience.

According to another aspect of the invention, there is provided acomputer program loadable into a computer and having the potential, whenrun on the computer, to provide the computer with the functionality of asystem according to the invention, a server according to the invention,or a client terminal according to the invention.

According to a last aspect of the invention, there is provided acomputer program loadable into a computer and having the potential, whenrun on the computer, to enable the computer to execute a methodaccording to the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be explained in further detail with reference tothe accompanying drawings, in which:

FIG. 1 is a schematic of a data distribution system according to oneembodiment of the invention;

FIG. 2 is a schematic of an encryption process according to oneembodiment of the invention;

FIG. 3 is a schematic of the decryption process according to oneembodiment of the present invention;

FIG. 4 is a schematic of the format of an MPEG-4 AU after encryption andaddition of a wrapper and Resync Markers, according to one embodiment ofthe invention;

FIGS. 5A and 5B are schematics illustrating the use of resynchronisationmarkers to resynchronise in the event of data loss, according to oneembodiment of the invention;

FIG. 6 is a diagrammatic representation of a machine in the exemplaryform of a computer system within which a set of instructions, forcausing the machine to perform any one of the methodologies discussedherein may be executed.

FIG. 7 is a schematic of a data packet used to distribute part or all ofa message through a network in the data distribution system of FIG. 1.

SPECIFIC DESCRIPTION

A method and system for a content-level encryption protocol aredescribed. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of the present invention. It will be evident, however, toone skilled in the art that the present invention may be practicedwithout these specific details.

In FIG. 1, a content encryption system 1 is used to generatecryptographically protected data encoding content. The data can havebeen created on the same system 1, or have been received from a separatesource. In any case, the data is arranged into messages. Each message isdecodable by a decoder application on a client system 2. The termmessage refers to the unit of data that the encoder application anddecoder application use for data exchange. In one example, to be usedthroughout this description, each cryptographically protected messagecomprises an encrypted MPEG-4 access unit (AU) 3 (see FIGS. 4, 5A and5B). An access unit is an individually accessible portion of data withinan elementary stream. An elementary stream is a consecutive flow ofmono-media data from a single source entity to a single destinationentity on the compression layer, the layer that translates between thecoded representation of an elementary stream and its decodedrepresentation and incorporates the decoders. It is, however, noted,that the invention can also be used with other types of messages, forexample MPEG-2 elementary stream packets.

In one embodiment, the encoded, encrypted messages generated by thecontent encryption system 1 are transferred to a first distributionserver 4 (FIG. 1), connected to a network 5 by means of a networkinterface, where they are stored. The client system 2 may access theencrypted content by downloading it from the server 4. When theencrypted access units 3 are downloaded, they are encapsulated in SyncLayer packets (SL-packets), consisting of a configurable header and apayload. The payload may consist of one complete access unit or apartial access unit. The SL-packets are subsequently mapped to anotherpacket format used in the network 5, e.g. RTP, MPEG-2 Transport Streampackets, or UDP. Of course, a scenario in which the content encryptionsystem 1 and first distribution server 4 are combined into a singleserver connected to the network 5 is also possible within the scope ofthe invention.

In another embodiment, the encoded, encrypted messages generated by thecontent encryption system 1 are stored on a content carrying medium 6,such as a CD-ROM, DVD-ROM or other suitable medium. Disk drive 7 is usedto load the encoded, encrypted messages from the content-carrying medium6 into the client system 2. In this embodiment, information is stored inthe files with the access units, in a format enabling an appropriateinterface on the client system 2 to retrieve and assemble the accessunits (e.g. into SL-packets). This information also allows the clientsystem 2 to pass the access units to the appropriate decoder buffers andthence the correct decoder application, after they have been read fromfile.

In both embodiments, the encrypted access units are stored in MP4-files.MP4-files typically carry the .mp4 extension. The MP4 file format isdesigned to contain the media information of an MPEG-4 presentation in aflexible, extensible format that facilitates interchange, management,editing, and presentation of the media. This presentation may be ‘local’to the system containing the presentation or may be via a network orother stream delivery mechanism. The file format is designed to beindependent of any particular delivery protocol while enabling efficientsupport for delivery in general. The design is based on the QuickTimeformat from Apple Computer Inc.

Preferably, the content encryption system 1 encrypts sections of theaccess units using at least one key (product or session key) having acycling key value. Content may be encrypted using a single product keyor a sequence of time-varying session keys, that are in turn encryptedwith the product key. The same encryption scheme can be used for video,audio and any associated data (the content). In other words, theinvention provides for content level encryption of MPEG-4 media anddata. Examples of the manner in which access units are encrypted will begiven below. In the preferred embodiment described herein, a symmetricalgorithm is used, i.e. the decryption key is the same as the encryptionkey. The scheme caters for selective encryption at both the intra-frameand inter-frame levels. (An example of where selective encryption may bedesirable could be low complexity devices and low value content that maywarrant the encryption of I-frames only, while other applications mayrequire the encryption of texture or motion vector information only.)

According to the invention, unique sequence numbers are added to messagesections. The encryption used is such as to enable the client system 2to decrypt each message section independently of the others, i.e.without knowledge of the data comprised in the other message sections.The content encryption system 1 generates at least one key message, eachkey message carrying data linking at least one unique sequence numberadded to a message to a key value enabling decryption of at least partsof that message.

The key messages are preferably also formed into an MPEG-4 elementarystream, i.e. into access units, identified by a separate elementarystream identifier (ES_ID). In the terminology of the MPEG-4 standard,these messages are called IPMP (Intellectual Property Management andProtection) Messages.

In one embodiment, the IPMP Messages are streamed from the firstdistribution server 4. In another embodiment, the IPMP Message stream isdownloaded by the client system 2 from a second distribution server 8.Alternatively, the IPMP Messages could be comprised in a separate fileon key stream carrying medium 9, distributed separately, for example aCD-ROM, DVD-ROM, flash memory device, smart card, etc.

In one embodiment, the key values are provided separately. In that case,the key messages contain pointers linked to sequence numbers, enablingthe keys to be retrieved by the client system 2. For instance, the keyscould be stored on the key stream carrying medium 9, whereas the IPMPMessage Stream is provided from the second distribution server 8.

In another embodiment, the key messages also contain the key values.Opaque data in the IPMP Message Stream could associate keys with mediain the following manner:

<key:1 ES=1 seqNum.begin=1 seqNum.end=54> <key:2 ES=1 seqNum.begin=54seqNum.end=169> <key:3 ES=1 seqNum.begin=169 seqNum.end=289>

The DTS (delivery time stamp: an indication of the nominal decoding timeof the access unit) of the access unit carrying a cycled session key maybe advanced so it arrives before the corresponding encrypted media AU(s)3 (which carry the data encoding the content). It is suggested that theDTS of the IPMP message stream be advanced by one key cycle period. Thiswould allow ample time for network jitter and any preprocessing on theclient system 2.

The information given above can then be used to associate key data withcontent access unit data to any granularity, regardless of the receivingterminal clock resolution.

As mentioned previously, the presence of unique sequence informationalso allows for sending the entire key stream prior to the delivery ofany media. In this case, the DTS of the media access units 3 is notrelevant and synchronization is performed purely on the value of theIPMP sequence numbers.

Overview

This invention may find application in all multimedia delivery systemswhere it is desired to perform effective content level encryption ofdata (e.g., MPEG-4 data) using cycled keys. This includes heterogeneousenvironments such as streaming over IP networks, as well as delivery ofMPEG-4 over MPEG-2 transport, or any other error-prone or error-freetransport mechanism that may be used to deliver MPEG-4 content.

As indicated above, one embodiment of this invention is based upon aframework for the protection of MPEG-4 content that uses two differentconstructs:

-   -   A secure wrapper for MPEG-4 access units; and    -   cryptographic Resync Markers.        These two constructs are discussed in detail below.

Detailed Description

Referring to FIG. 4 in particular, the content encryption system 1 readsan original access unit 10 from a machine-readable medium. In thisexample, the original access unit 10 is separated into three sections,which are independently encrypted, resulting in the encrypted accessunit 3, comprising a first encrypted AU section 11, a second encryptedAU section 12 and a third encrypted AU section 13. A first Resync Marker14 is added to the second encrypted AU section 12, separating it fromthe first encrypted AU section 11. A second Resync Marker 15 is added tothe third encrypted AU section 13, separating it from the secondencrypted AU section 12. A header 16 is prepended to the encrypted AU 3.

1. Secure Wrapper

In one exemplary embodiment of the invention, the secure wrapper of thisinvention may be thought of as a cryptographic encapsulation envelopethat provides security for any “wrapped” MPEG-4 access unit (videoframe, audio sample, data unit). The publisher/server/owner protects thecontent by wrapping individual Aus 3 in these envelopes. The content maythen only be unwrapped by an end-user who has the appropriatekey/rights. Wrappers of various kinds are quite common and appear in anumber of cryptographic protocols. Thus, this invention can operate witha generic wrapper.

In one exemplary embodiment, the wrapper may specifically be defined foruse in the MPEG-4 environment. In addition, this invention may usecharacteristics of the wrapper (the sequence number, etc.) to do “doubleduty”, by also providing the capability to cycle keys, and performrandom access. Thus, this invention may operate by taking a number ofwidely used protocols, and adding thereto specific constructs (such asthe Resync Markers 14,15) to create a solution by putting them alltogether in a framework and using them in a certain way.

The header 16 shown below (and schematically in FIG. 4) is pre-pended toeach encrypted AU 3:

Payload (Encrypted/Authenticated/AU) 0 1 2 3 4 5 6 7 Version = E A CRMReserved 00 Sequence Number (variable length) Authentication code(variable length, optional)The header 16 comprises the following fields:

Version—two-bit version field 17. Set to zero for the first revision.

E—Bit flag 18 indicating whether the payload is encrypted (1) or clear(0). Note that only the Payload portion is encrypted.

A—Bit flag 19 indicating the presence (1) or not (0) of theAuthentication Code field. If present, the authentication code relatesto the entire structure—wrapper 16 and AU 3.

CRM—Bit flag 20 indicating presence (1) or not (0) of crypto ResyncMarkers 14,15 within the AU 3.

Reserved—field 21 of three reserved bits—set to zeros.

Sequence Number—A unique sequence number, carried in a sequence numberfield 22. The method of generation of the sequence number is consideredoutside the scope of this document. The value may be monotonicallyincreasing, since Hamming distance attacks do not pose a significantthreat against AES in counter mode The length of this field 22 is notpreset, since it uses a self-describing format. The lower seven bits ofeach byte are used for carrying the sequence number. The setting of thehigh order bit of each byte indicates the presence of another byte,while the last byte has its MSB set to zero.

As an example, the value 350 would be represented as follows:11010111 00000010

Authentication Code—An optional field (not shown in FIG. 4) carries aself-describing authentication code. The framework is agnostic to theauthentication code scheme to be used, but it is assumed that a keyedhash (HMAC) would be most suitable. Digital signatures are catered for,but the assumption is that these schemes are currently too expensive tobe performed at the AU level. Note that the entire structure—header16+AU 3 is authenticated.

Payload—The original AU 10 or encrypted AU 3. In the event that CryptoResync Markers 14,15 are used, the encrypted AU 3 will be larger thanthe original 10.

2. Crypto Resync Markers

In order to enable cryptographic resynchronisation, the markers 14,15carry some unique and explicit synchronization information 23,24,respectively, to allow the cipher to be “reset” in the event of dataloss.

The following is a Crypto Resync Marker that performs well in theencrypted domain. The marker is byte aligned, and consists of sixteenzeros followed by a variable length, self describing sequence counter:0000 0000 0000 0000 XXXX XXXX

In application, multiple crypto Resync Markers 14,15 may be inserted ina single AU 3. Markers 14,15 located within the AU 3 are easilylocatable and therefore guaranteed to be unique. There is a smallstatistical probability that collisions may still result, since a givenplaintext/key combination may result in ciphertext that has the form0000 0000 0000 0000. Although the probability of this happening isextremely low, the possibility of marker emulation may be removedcompletely by the use of escape codes. In such an embodiment thepresence of emulated Resync Markers is announced by “escaping” them, ina similar manner to C language escape codes.

For typical usage in an error-prone environment, a number of ResyncMarkers 14,15 may be placed within a given AU 3. The body of each ResyncMarker 14,15 contains a unique counter 25,26, respectively that has thesame format and usage as the sequence number in the secure wrapper. Itis suggested that the counter 25,26 increment monotonically from theinitial sequence number carried in the header 16.

Corruption or loss of the sequence number contained in the header 16does not result in loss of the entire encrypted AU 3. The sequencenumber within the Resync Marker is preferably absolute, rather thanspecified as an offset from the sequence counter specified in the header16. It is also important to ensure that the value of the sequence numberin the header of the following AU is greater than the last sequencenumber used in the current AU 3 in order to avoid using the cipher indepth.

An example of a Resync Marker with a value of 351:0000 0000 0000 0000 1000 0010 0101 1111

In the event of data loss, locating the next Resync Marker, and usingthe sequence value in the body of the markers as input to the IV torestart the cipher may achieve synchronization.

Implementation

1. Encryption

FIG. 2 is a schematic of the encryption process according to onepreferred embodiment of the invention. A counter 27 is formed from asalting key 28, a sequence number 29 and a block index 30. An encryptedcounter 31 is generated using a key 32 with a cycling value. Theencrypted counter is XOR-ed with a clear AU data block 33, generating anenciphered AU data block 34.

The AES/Rijndael algorithm has been selected for media encryption. Thecipher is run in counter mode and makes use of explicit counters(sequence numbers and crypto Resync Markers) carried within the media.

The Rijndael algorithm was selected as the new Federal InformationProcessing Standard (FIPS) for data encryption and is poised to replacethe aging DES and Triple DES standards.

The AES algorithm has been subjected to a significant amount ofcryptanalysis during the selection process. The level of analytic effortthrown at AES is comparable to DES. It is widely accepted that thebest-known attack method is exhaustive search of the key space.

Some highlights of AES are:

-   -   Royalty free and unclassified    -   Available for worldwide export    -   allows variable 128, 192 & 256 key and block sizes. All nine        combinations of key/block length are possible.    -   Vast speed improvement over DES in both hardware and software        implementations:    -   8.416 kB/s on a 20 MHz 8051    -   8.8 MB/s on a 200 MHz Pentium

These figures are quoted for ECB mode. Counter mode requires only anadditional XOR operation, and thus adds negligible overhead.

Counter mode grew out of the need for high-speed encryption of ATMnetworks that required parallelisation of the encryption algorithm.

Counter mode encryption operates by applying an encryption function to amonotonically increasing counter 27 to generate a one-time pad. This padis then XORed with the plaintext. The decryption operation is identical.

Counter mode requires that sender and receiver share a counter inaddition to sharing the usual secret key 32. Note that the counter 27doesn't need to be secret.

For encryption:

Ci=Pi XOR E (counter)

For decryption:

Pi=Ci XOR E (counter)

With the following-notation:

E( ) is the encryption function of a block cipher.

Ci is the i-th block of ciphertext.

Pi is the i-th block of plaintext.

It is extremely important that the same counter value not be reused forthe same key, since an attacker can then XOR two cipher blocks andobtain an XOR of the two corresponding blocks of plaintext.

Advantages of Counter Mode are:

1. Software efficiency. Since the generation of the key stream isindependent of the message, pre-processing may be used in someenvironments. The pad may be computed in spare cycles, even before themedia is available. When the media becomes available, it is simply XORedwith the pad. This can result in a throughput of tens of Gbits/s on acontemporary processor.

2. Hardware efficiency. Counter mode is fully parallelisable. Blocks C1,C2, . . . Cn may all be decrypted at the same time.

3. Random access. No chaining, thus no dependency on the Ci−1 th blockin order to decrypt Ci.

4. 1 bit error extension. Ciphertext error is limited to thecorresponding bit in the plaintext. This is a highly desirable propertyfor streaming video applications in a lossy environment.

5. Low complexity. Both the encryption and decryption processes dependon the encryption function E( ). This is an important criteria when theinverse direction of a cipher D( )=E( )−1 is very different from the“forward” direction. This is the case for Rijndael and many other blockciphers. This makes for extremely low small footprint hardware andsoftware solutions

6. Security. As secure as the underlying block cipher.

7. No increase in size of ciphertext. Ignoring for a moment the use ofan explicit Resync Marker, there is no expansion of the ciphertext.

The cipher has known cryptographic strength against an appropriate setof attack methods and has undergone extensive analysis by the worldcryptographic community, and is widely adopted. The cipher itself isalmost universal, having been accepted by NIST (National Institute ofStandards and Technology. The cipher supports a key length of at least128 bits. Scalability is important, since ideally the same cipher shouldbe capable of being parameterised to protect content that may differwidely in value—from three-minute video clips to Hollywood blockbusters.Key lengths of greater than 128 bits may be overkill for certainapplications; support for longer keys is considered an advantage.Adoption of a single parameterised algorithm also promises economy ofscale benefits to silicon vendors. The invention does not use obscureciphers or well-known ciphers in obscure modes. The cryptosystem isself-synchronizing, providing random access or seek capabilities, aswell as recovery from data loss. Although these are different scenarios,in practice they depend on the same criteria: the lack of all or part ofany preceding data blocks does not influence the ability to decrypt thecurrent data block. The availability of reliable (explicit or implicit)continuity information for the data to be decrypted can therefore beassumed. The cryptosystem provides good error propagationcharacteristics. Single bit error extension (a bit error in the ciphertext results in only the corresponding bit in the plaintext being inerror) is very important. Schemes with same block, multiple block orinfinite error extension properties do not apply. The cipher offers goodperformance in both hardware and software across a wide range ofcomputing environments. Key set-up time, key agility and parallelism areall important. The choice of algorithm reflects a “security to a point”policy in which acceptable security concessions are made to increaseefficiency and reduce complexity. The cryptosystem offers low dataexpansion. The size of the resulting cipher text is the same as or closeto that of the plaintext, and the size of any additional “securityheaders” is kept to a minimum. Encryption of more than one message withthe same product or session key is possible, without compromisingsecurity in any way.

2. Decryption

FIG. 3 is a schematic of the decryption process (not the symmetry of theencryption/decryption process) according to one embodiment of theinvention.

Decryption proceeds as follows in one exemplary embodiment of thepresent invention:

The decryption engine checks the Encryption flag 18 in the wrapper ofthe AU 3. If the flag 18 is not set, and no authentication is used, thewrapper may simply be removed, and the original AU 3 passed to thedecoder.

If the AU 3 is encrypted, the sequence number in the wrapper isextracted, and used to generate the counter 27.

The counter block size is the same as the selected AES block size. Thisrequirement is due to the fact that the counter 27 is input to the blockcipher. This approach is extensible, since it is relatively easy to padthe counter 27 to a larger size in the event that a larger AES blocksize is specified.

For the purposes of this text, an AES block size of 128 bits will beassumed:

 0 32  96 31 95 127 Salting Sequence Number Block key index (optional)

The salting key 28 is optional, but it should be noted that the lack ofa salting key 28 would lead to a complete breakdown of security in theevent that multiple bit streams are encrypted with the same key 32. (If,for example, audio and video are encrypted with the same product andsession keys, then one or more salting keys 28 are used to prevent usingthe cipher in depth.) The value of the salting key 28 does not have tobe secret.

The 32-bit block index 30 is the block count within a single AU 3. Thefirst 128-bit block of an AU has the index 0; the next has 1 and so on.The block index is reset to zero after every Resync Marker 14,15. Notethat the value of the block index 30 is not transmitted, but is computedby the encryption and decryption processes.

The block index 30 must never cycle during the processing of an AU 3.Assuming the worst case of a 128 bit AES block size and a maximallysized video AU 3, a 32-bit block size offers more than enough headroom.

The counter block 27 is then used as the input of the AES block cipherduring the pad computation. The processing of the i-th block of an AUis:

Ci=Pi XOR E( counter ) for the encryption process

Pi=Trunc (n, Ci XOR E(counter)) for the decryption process

With the following notation:

E( ) is the encryption function of the AES cipher.

Ci is the i-th block of the encrypted MPEG-4 AU.

Pi is the n first bytes of the i-th block of the original AU data. Thevalue of n is between 1 and the block size.

The assumption is that the length of each AU 3 is provided to thedecryption tool together with the AU data.

The Trunc(x,y) function truncates the x first bytes of the y value.

In the case where Crypto Resync Markers 14,15 are used, the followingactions must be taken:

The CRM flag 20 is checked. If CRMs are present in the AU 3, thendecryption proceeds as above until a CRM is encountered.

The bit stream is checked to ensure that this is not an emulated CRMthat has been escaped. If this is an emulated marker, then the markershould be “un-escaped” and decryption should proceed as normal.

If the marker 14,15 is valid, then the body of the marker should be usedto generate a new counter 27:

 0 32  96 31 95 127 Salting Crypto Resync Marker Block key index(optional)

The Block index 30 is reset to zero, and decryption proceeds using thisnew counter value as input to the cipher.

3. Configuring the Cryptosystem

In one exemplary embodiment of the present invention a, number ofparameters may be needed to be set in order to use the cryptosystemeffectively.

These may include, for example

-   -   The Authentication scheme to be used (if any).    -   The salting keys 28. Since these do not have to be secret, they        could be carried with the configuration information    -   The decryption cipher and mode. If none is specified, then it is        assumed to be AES in counter mode.    -   If intra-frame selective encryption is used, a description of        exactly what data is encrypted.

This information is carried in the IOD (initial object descriptor). Theexact format of the data structures to be used is considered outside thescope of this document.

FIG. 6 shows a diagrammatic representation of machine in the exemplaryform of a computer system 35 within which a set of instructions, forcausing the machine to perform any one of the methodologies discussedabove, may be executed. In alternative embodiments, the machine maycomprise a set-top box (STB), a network router, a network switch, anetwork bridge, Personal Digital Assistant (PDA), a cellular telephone,a web appliance or any machine capable of executing a sequence ofinstructions that specify actions to be taken by that machine.

The computer system 35 includes a processor 36, a main memory 37 and astatic memory 38, which communicate with each other via a bus 39. Thecomputer system 35 may further include a video display unit 40 (e.g., aliquid crystal display (LCD) or a cathode ray tube (CRT)). The computersystem 35 also includes an alphanumeric input device 41 (e.g., akeyboard), a cursor control device 42 (e.g., a mouse), a disk drive unit43, a signal generation device 44 (e.g., a speaker) and a networkinterface device 45.

The disk drive unit 43 includes a machine-readable medium 46 on which isstored a set of instructions (i.e., software) 47 embodying any one, orall, of the methodologies or functions described herein. The software 47is also shown to reside, completely or at least partially, within themain memory 37 and/or within the processor 36. The software 47 mayfurther be transmitted or received via the network interface device 45.For the purposes of this specification, the term “machine-readablemedium” shall be taken to include any medium that is capable of storing,encoding or carrying a sequence of instructions for execution by themachine and that cause the machine to perform any one of themethodologies of the present invention. The term “machine-readablemedium” shall accordingly be taken to included, but not be limited to,solid-state memories, optical and magnetic disks, and carrier wavesignals.

FIGS. 5A and 5B jointly form a schematic illustrating the use of CryptoResync Markers 14,15 to resynchronise in the event of data loss,according to one embodiment of the present invention. FIG. 5A representsthe prior art. No Resync Markers are present. The encrypted AU 3 merelyhas the header 16 prepended to it. Suppose the client system 2 toreceive the encrypted access unit 3 with a block of lost data 49. Usinga block cipher in counter mode with only the sequence number of theheader 16 being utilisable as initialisation vector, the client system 2would only be able to decrypt the encrypted access unit 3 correctly upto the lost data 49. After that, it would continue to decrypt theencrypted access unit 3, but would use the wrong counter value inconnection with the wrong data block, thus producing garbled plaintext.In effect the decryption process would result in a block 50 of recovereddata and a (relatively large) block 51 of lost AU data.

In contrast, the use of crypto Resync Markers 14,15, as shown in FIGS.5B and 4, means that the decryption process results in a first recoveredAU data part 52, a (much smaller) block 53 of lost AU data, and a secondrecovered AU data part 54. This is due to the fact that the clientsystem 2 is able to recognise the explicit synchronisation information23 and 24 in the resynchronisation markers 14 and 15, respectively. Toextract each of the first, second and third AU sections 11-13, anddecrypt them independently.

Turning now to FIG. 7, there is shown a schematic diagram of an IPpacket 55, used to distribute the encrypted AU 3 over the network 5 toclient system 2. The IP packet 55 comprises an IP header 56, comprisinga network address, from which the client system 2 can tell whether it isan or the intended recipient of the IP packet 55. The IP address can bea unique address, a multicast address, or a broadcast address, as isknown in the art.

In the exemplary embodiment, UDP is used as the transport protocol.Accordingly, the IP packet 55 comprises a UDP header 57. Additionally,the encrypted access unit 3 has been encapsulated by an applicationimplementing the sync layer, defined in the MPEG-4 standard, on thefirst distribution server 4. Accordingly, the IP packet comprises an SLheader 58. Directly after the SL header 58 comes a header 59 that formsthe secure wrapper. It is identical to the header 16 described above,except that it further comprises an explicit synchronisation sequence60, identical to the explicit synchronisation information 23,24 of thecrypto Resync Markers 14,15. The header 59 further comprises the bitflag 18 indicating encryption of the access unit 3, the bit flag 19indicating authentication, the CRM flag 20, the reserved field 21 andthe sequence number field 22. The first encrypted AU section 11 followsthe header 59. The second encrypted AU section 12 is separated from thefirst encrypted AU section 11 by the first crypto Resync Marker 14,comprising the synchronisation information 23 and counter 25. The thirdencrypted AU section 13 is separated from the second encrypted AUsection 12 by the second crypto Resync Marker 15, comprising thesynchronisation information 24 and counter 26.

The synchronisation information 23,24,60 is advantageously exploited bythe present invention to implement a type of decryption known asdecryption under the stack. This type of decrypt is described more fullyin co-pending international patent application PCT/US01/41361 by thesame applicant as the present application.

The client system 2 comprises an interface that implements the IPprotocol. That is to say, the interface processes the IP packet 55 usinginformation in the IP header 56 to determine what to do with theremainder of the IP packet 55. Whereas usually, the remainder is passedto an interface implementing a higher level protocol, i.e. the UDPprotocol in this case, and from there on up further, i.e. to aninterface implementing the MPEG-4 sync layer in this example, in thepresent embodiment of the invention, the IP packet 55 is firstdecrypted.

In this embodiment, the client system 2 receives the entire IP packet 55as input from the interface implementing the IP protocol on the clientsystem 2. It is agnostic about the remainder of the IP packet 55, but itsearches the data in the payload of the IP packet 55 for the explicitsynchronisation information 23,24,60. It then extracts the encryptedmessage sections from the IP packet 55 to decrypt them using the methodsdescribed above. Subsequently, the IP packet 55 is re-assembled, andpassed back to the interface implementing the IP protocol on the clientsystem 2, whereupon it is processed by the various interfacesimplementing the other protocols, i.e. UDP, SL.

Thus, a method and system for a content level encryption protocol havebeen described. Although the present invention has been described withreference to specific exemplary embodiments, it will be evident thatvarious modifications and changes may be made to these embodimentswithout departing from the broader spirit and scope of the invention.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

1. A method of generating cryptographically protected digital dataencoding content and arranged into messages, each message beingdecodable by a decoder application on a client terminal having a serviceinterface to assemble each message for the decoder application, themethod including: retrieving a message from a machine-readable medium;encrypting at least part of the message; and providing the encryptedmessages as output in a format enabling a server service interface toarrange the message into at least one packet including at least oneheader and a payload, each payload including at least part of themessage, at least one header including information enabling the serviceinterface on the client to assemble each message for the decoderapplication from the payload of the packets, wherein the method furthercomprises separating each message into a first and at least one furthermessage section, wherein at least one of the message sections isencrypted in such a way as to be decryptable independently of the othermessage sections, and wherein the encrypted message is assembled byadding a resynchronisation marker, separating a message section from anadjacent message section and including explicit synchronisationinformation, to at least the further message sections.
 2. A methodaccording to claim 1, wherein the message sections are encrypted usingat least one key having a cycling value.
 3. A method according to claim2, further comprising generating at least one key message, each keymessage carrying data linking at least one unique sequence number addedto a message to a key value enabling decryption of at least parts ofthat message.
 4. A server for enabling decryption of cryptographicallyprotected data encoding content and arranged into messages, generated bymeans of a method according to claim 2, wherein the server is arrangedto transfer at least one key message, each key message carrying datalinking at least one unique sequence number added to a message to a keyvalue enabling decryption of at least parts of that message, in responseto a request from a client terminal, connected to the server through anetwork.
 5. A method according to claim 1, wherein eachresynchronisation marker further includes a unique sequence number.
 6. Amethod according to claim 5, wherein each unique sequence number isprovided in a self-describing format.
 7. A method according to claim 5,further comprising encrypting message sections by employing a cipher ina cryptographic mode using feedback, wherein the cipher isre-initialised at the start of each message section.
 8. A methodaccording to claim 7, wherein a unique sequence number in aresynchronisation marker separating a further message section fromanother message section is used as an initialisation vector to encryptthe further message section.
 9. A method according to claim 1, furthercomprising adding a wrapper that encapsulates each encrypted message andincludes a unique sequence number.
 10. A method according to claim 1,wherein a block cipher is used to encrypt a message section and thecipher uses a cipherblock size equal to a divisor of a message sectionsize.
 11. A method according to claim 1, further comprising employing acipher in a counter mode, wherein a counter is re-set before encryptinga message section.
 12. A method according to claim 11, wherein a uniquesequence number in a resynchronisation marker separating a furthermessage section from another message section is used to form the counterto encrypt the further message section.
 13. A method according to claim11, wherein messages belonging to separate elementary streams areencrypted, each stream intended for a decoder application on the client,the method comprising providing the encrypted messages as output in aformat enabling the service interface on the client to assemble themessage into separate elementary streams, wherein the counter is formedfrom a salting key, a different salting key being used for the messagesof each elementary stream.
 14. The method of claim 1, wherein separatingeach message includes placing both the message section and the adjacentsection in a same payload and separating the message section and theadjacent section with the resynchronization marker.
 15. The method ofclaim 14, wherein separating each message includes placing both themessage section and the adjacent section under a single header.
 16. Asystem for generating cryptographically protected digital data encodingcontent and arranged into messages, each message being decodable by adecoder application on a client terminal having a service interface toassemble each message for the decoder application, the system beingconfigured to: retrieve a message from a machine-readable medium;encrypt at least part of the message; and to provide the encryptedmessages as output in a format enabling a server service interface toarrange the message into at least one packet including at least oneheader and a payload, each payload including at least part of themessage, at least one header including information enabling the serviceinterface on the client to assemble each message for the decoderapplication from the payload of the packets, wherein the system isconfigured to separate each message into a first and at least onefurther message section, to encrypt at least one of the message sectionsin such a way as to be decryptable independently of the other messagesections, and to assemble the encrypted message by adding aresynchronisation marker, separating a message section from an adjacentmessage section and including an explicit synchronisation sequence, toat least the further message sections.
 17. A system according to claim16, wherein the system is configured to encrypt the message sectionsusing at least one key having a cycling value.
 18. A system according toclaim 17, wherein the system is further configured to generate at leastone key message, each key message carrying data linking at least oneunique sequence number added to a message to a key value enablingdecryption of at least parts of that message.
 19. A system according toclaim 16, wherein each resynchronisation marker further includes aunique sequence number.
 20. A system according to claim 19, wherein thesystem is configured to provide each unique sequence number in aself-describing format.
 21. A system according to claim 19, wherein thesystem is further configured to encrypt message sections by employing acipher in a cryptographic mode using feedback, wherein the system isconfigured to re-initialise the cipher at the start of each messagesection.
 22. A system according to claim 21, wherein the system isfurther configured to use a unique sequence number in aresynchronisation marker separating a further message section fromanother message section as an initialisation vector to encrypt thefurther message section.
 23. A system according to claim 19, wherein thesystem is configured to use a unique sequence number in aresynchronisation marker separating a further message section fromanother message section to form the counter to encrypt the furthermessage section.
 24. A system according to claim 16, wherein the systemis further configured to add a wrapper that encapsulates each encryptedmessage and includes a unique sequence number.
 25. A system according toclaim 16, wherein the system is configured to use a block cipher toencrypt a message section and the cipher uses a block size equal to adivisor of the message section size.
 26. A system according to claim 16,wherein the system is further configured to employ a cipher in countermode, and to re-set the counter before encrypting a message section. 27.A system according to claim 26, wherein the system is capable ofencrypting messages belonging to separate elementary streams, eachstream intended for a decoder application on the client, wherein thesystem is configured to provide the encrypted messages as output in aformat enabling the service interface on the client to assemble themessage into separate elementary streams, wherein the system isconfigured to form the counter from a salting key, and to use adifferent salting key for the messages of each elementary stream. 28.The system of claim 16, wherein the system is configured to form acrypted message including a single header, a first message section, asecond message section, a third message section, a firstresynchronization marker separating the first message section from thesecond message section, and a second resynchronization marker separatingthe second message section from the third message section.